Access Control for Internet of Things Devices

ABSTRACT

Requesting, by a requesting device, from an Internet of Things (IoT) device, an IoT device identifier over a communication link between the devcies. Requesting, by the requesting device from an authorization device over a communication network including at least one TCP/IP link, authorization to command the IoT device to perform an action. Determining, by the authorization device, an authorization of the requesting device to command the identified IoT device to perform the requested action based on the IoT device identifier, the requesting device identifier, and the command. For a requesting device determined authorized, transmitting an encrypted authorization to the requesting device over the communication network. Relaying, by the requesting device to the IoT device via the first communication link, the authorization. Decrypting, by the IoT device, the authorization and performing the action specified therein.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.62/202,879, filed Aug. 9, 2015, and entitled “Access Control forInternet of Things Devices,” the entire contents of the above-identifiedpriority application are hereby fully incorporated herein by reference.

TECHNICAL FIELD

The technology disclosed herein relates to Internet of Things (IoT)devices. Example embodiments relate to controlling access to IoT devicesindirectly or unreliably connected to the Internet.

BACKGROUND

The “Internet of Things” typically refers to the connection of “things”(hereinafter “IoT devices”), such as sensors, household appliances,security devices, utility meters, and even mundane consumer products(other than traditional end user computing devices, for example,computers, tablets, and smartphones) to the Internet. Such connection isnot limited to IoT devices that implement the Internet protocol suite,commonly referred to as Transmission Control Protocol (TCP)/InternetProtocol (IP), but also includes IoT devices indirectly connected to theInternet via an IoT gateway. An IoT device indirectly connected to theInternet through an IoT gateway can implement a communications protocolsuite, such as the protocols used in Bluetooth® wireless personal areanetwork (PAN) technology, between the IoT device and the IoT gateway.Such an IoT device may have only an unreliable connection, if any,(whether direct or indirect) to the Internet.

SUMMARY

Methods, computer program products, and system to control access to IoTdevices are disclosed herein. In some embodiment, a requesting devicedevice first requests, from an IoT device, an IoT device identifier ofthe IoT device over a first communication link between the requestingdevice and the IoT device. The requesting device receives, from the IoTdevice, the requested IoT device identifier. The requesting devicesecond requests, from an authorization device over a communicationnetwork including at least one Transmission Control Protocol/InternetProtocol (TCP/IP) communication link, authorization to command theidentified IoT device to perform an action. The authorization devicereceives the second request, and determines, in response to receivingthe second request, an authorization of the requesting device to commandthe identified IoT device to perform the requested action. For arequesting device determined, the authorization device, authorized tocommand the identified IoT device to perform the requested action,transmits an encrypted authorization for the requesting device tocommand the IoT device to perform the action, to the requesting deviceover the communication network. The requesting device receives thetransmitted encrypted authorization via the communication network. Therequesting device then relays, to the IoT device via the firstcommunication link, the received transmitted encrypted authorization.The IoT device receives the encrypted authorization from the requestingdevice via the first communication link, decrypts the receivedauthorization, and performs the action specified in the authorization.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram depicting a communications and processingarchitecture for controlling access to IoT devices in accordance withcertain example embodiments.

FIG. 2 is a diagram depicting generalized data flows, in thecommunications and processing architecture of FIG. 1, for controllingaccess to IoT devices 120, in accordance with certain exampleembodiments.

FIG. 3 is a block flow diagram depicting processes for controllingaccess to IoT devices, in accordance with certain example embodiments.

FIG. 4 is a block diagram depicting a computing machine and a module, inaccordance with certain example embodiments.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS Overview

IoT devices often carry sensitive information. For example, a heartbeatsensor should only share heartbeat data with the user's device or withauthorized medical equipment. IoT devices can also perform actions thatonly authorized users or other authorized devices should be able totrigger; for example, unlocking the door to a garage or a house. Beforetransmitting sensitive information or initiating a privileged action,the IoT device should identify, authenticate, and check access controllists (ACLs) for the entity requesting the information or the action.The IoT device also should address the risk of eavesdroppersintercepting the data or performing replay attacks.

Since some IoT devices are not directly or continuously connected to theInternet, traditional approaches for identification and authenticationto control access to such IoT devices will not work as well as thoseapproaches work for directly/reliably connected devices. In particular,remotely revocable access control, such as through use of an ACL, is achallenge with traditional approaches.

Consider, as an example, a group of smart water meters in a non-TCP/IPmesh network with intermittent indirect Internet access through aneighborhood Internet gateway. Given the intermittent indirect Internetaccess, the water company cannot readily edit an ACL on each IoT device.A local agent, who may not be identifiable to a particular IoT device,may need to interact with the IoT device—for example, to collect waterusage data, or to program, install, or calibrate the device on behalf ofthe device owner.

Embodiments herein provide computer-implemented techniques forcontrolling access to an IoT device. In particular, when a requestingdevice requests access (for example, to extract data from the IoTdevice, or command the IoT device) over a non-TCP/IP communicationslink, the IoT device responds by sending an IoT device token over thenon-TCP/IP communications link. The requesting device passes the IoTdevice token, along with a token of the requesting device, to anauthorization device, such as an access control server, over a firstcommunications network, for example, an Internet connection. The accesscontrol server uses the requesting device's token and the IoT device'stoken to determine, for example, through use of an access control list(ACL) on the access control server, if the requesting device should begranted access the IoT device. If so, then the access is granted. Ifnot, then access is not granted. A requesting device described hereinmay be any kind of network device that is capable of communicating withan IoT device via a communication network.

By using and relying on the methods and systems described herein,embodiments of the present technology leverage the connectivity of therequesting device to allow simpler IoT devices. Simpler IoT devicesenabled by the present technology do not have to establish and update anindependent ACL and do not have to maintain a reliable or direct networkconnection with the access control server over the Internet. Thus, theIoT devices enabled by the present technology require less processingpower and consume less transmission bandwidth over the non-TCP/IPcommunications link. As such, the systems and methods described hereinmay be employed to reduce the cost of such devices and to increase theability of the overall system to respond to change. For example, changesto the ACL of a given device do not require access to the device itself.In addition, such an approach makes it more difficult for anunauthorized entity to compromise the IoT device; in part, because theIoT device does not control which other devices access it. Thus, themethods and systems described herein possess the potential to provideenhanced network security.

Turning now to the drawings, in which like numerals represent like (butnot necessarily identical) elements throughout the figures, exampleembodiments are described in detail. In certain example embodiments, auser associated with a device must install an application and/or make afeature selection to obtain the benefits of the techniques describedherein. Throughout the discussion of example embodiments, it should beunderstood that the terms “data” and “information” are usedinterchangeably herein to refer to text, images, audio, video, or anyother form of information that can exist in a computer-basedenvironment.

Example System Architectures

FIG. 1 is a block diagram depicting a communications and processingarchitecture 100 for controlling access to IoT devices in accordancewith certain example embodiments. As depicted in FIG. 1, thearchitecture 100 includes devices 110, 120, and 130 that can beconfigured to communicate with one another via one or more firstnetwork(s) 199. The direct communications link 150 between IoT device120 and the one or more first network(s) 199 can be characterized as oneor more of optional, unreliable, intermittent, or even non-existent. Incertain example embodiments, a user associated with a device mustinstall an application and/or make a feature selection to obtain thebenefits of the techniques described herein.

Each device 110 and 130 (and in some instances 120) includes a devicehaving a communication module capable of transmitting and receiving dataover the first communications network(s) 199. For example, each networkdevice 110 and 130 can include a server, desktop computer, laptopcomputer, tablet computer, a television with one or more processorsembedded therein and/or coupled thereto, smart phone, handheld computer,personal digital assistant (“PDA”), or any other wired or wireless,processor-driven device. Each device 120 can be an IoT device. In theexample embodiment depicted in FIG. 1, an IoT device owner, or an agentof the IoT device owner, can operate devices 110, 120, and 130. In otherexample embodiments, while the requesting device 110 and the IoT device120 can be owned and operated by the same person, the authorizationdevice 130 can be a server operated by a second party.

The first communications network(s) 199 include wired or wirelesstelecommunication systems or devices by which network devices (includingdevices 110 and 130, and in some instances 120) can exchange data. Forexample, the first communications network(s) 199 can include a localarea network (“LAN”), a wide area network (“WAN”), an intranet, anInternet, storage area network (SAN), personal area network (PAN), ametropolitan area network (MAN), a wireless local area network (WLAN), avirtual private network (VPN), a cellular or other mobile communicationnetwork, a BLUETOOTH® wireless technology connection, a near fieldcommunication (NFC) connection, or any combination thereof or any otherappropriate architecture or system that facilitates the communication ofsignals, data, and/or messages.

It will be appreciated that the network connections shown are exampleand other means of establishing a communications link between thecomputers and devices can be used. Additionally, those having ordinaryskill in the art and having the benefit of the present disclosure willappreciate that devices 110 and 130 illustrated in FIG. 1 can have anyof several other suitable computer system configurations. For example, arequesting device 110 can be embodied as a mobile phone or handheldcomputer, and may not include all the components described above.

In example embodiments, the network computing devices and any othercomputing machines associated with the technology presented herein maybe any type of computing machine such as, but not limited to, thosediscussed in more detail with respect to FIG. 4. Furthermore, anyfunctions, applications, or components associated with any of thesecomputing machines, such as those described herein or any others (forexample, scripts, web content, software, firmware, hardware, or modules)associated with the technology presented herein, may by any of thecomponents discussed in more detail with respect to FIG. 4. Thecomputing machines discussed herein may communicate with one another, aswell as with other computing machines or communication systems over oneor more networks, such as first communications network(s) 199. The firstcommunications network(s) 199 may include any type of data orcommunications network, including any of the network technologydiscussed with respect to FIG. 4.

Example Processes

The example methods illustrated in FIGS. 2-3 are described hereinafterwith respect to the components of the example operating architecture100. The example methods of FIGS. 2-3 may also be performed with othersystems and in other environments. The operations described with respectto any of FIGS. 2-3 can be implemented as executable code stored on acomputer or machine-readable non-transitory tangible storage medium(e.g., floppy disk, hard disk, ROM, EEPROM, nonvolatile RAM, CD-ROM,etc.). The operations are completed based on execution of the code by aprocessor circuit implemented using one or more integrated circuits. Theoperations described herein also can be implemented as executable logicthat is encoded in one or more non-transitory tangible media forexecution (e.g., programmable logic arrays or devices, fieldprogrammable gate arrays, programmable array logic, application specificintegrated circuits, etc.).

Consider, as context for the technology described herein, a hands-freepayment technology. In embodiments of a hands free payment system, amerchant registers with a payment processing system. A user establishesan account with the payment processing system and transmits an image ofhimself to the payment processing system to establish a facial templateassociated with the user account. A user signs into the paymentapplication via the user computing device and enters the merchant systemlocation.

The user computing device receives a merchant beacon device identifierfrom a merchant beacon device, implemented as an IoT device 120 of thepresent technology, and transmits the identifier to the paymentprocessing system. The payment processing system transmits facialtemplates to a merchant camera device (which can also be an IoT device120) corresponding to users whose user computing devices are in networkrange of the merchant beacon IoT device 120 and who are signed in to thepayment application. The merchant camera device captures a facial imageof the user and identifies the user by comparing the captured facialimage against the received facial templates. A merchant point of saledevice operator selects an account of the user for use in a transactionfrom one or more displayed accounts of the user. The merchant point ofsale device transmits transaction details to the payment processingsystem, which generates a transaction authorization request to transmitto an issuer system associated with the user account selected for use inthe transaction. The payment processing system receives an approval ofthe transaction authorization request and transmits a receipt to themerchant point of sale device.

FIG. 2 is a diagram depicting generalized data flows 200, in thecommunications and processing architecture of FIG. 1, for controllingaccess to IoT devices 120, in accordance with certain exampleembodiments. In a continuing example embodiment, an installer ormaintainer (hereinafter “installer”) may use the present technology tointeract with a merchant beacon 120. The installer may use the presenttechnology to send configuration commands from a Bluetooth-enabledtablet computer 110 running a merchant beacon interface application to amerchant beacon 120 over a Bluetooth communications link 140. Theinstaller also may request sensitive data (such as security camerafootage) from an merchant beacon/IoT device 120. The personnel who areauthorized to configure a merchant beacon 120 may change. Embodiments ofthe present technology can be used to permit/revoke an installer'spermissions.

An application on the requesting device 110 can send a request foraccess to the IoT device 120 over the first communications link 140—DataFlow 210. In the continuing example, the installer initiates a requestin an application on a Bluetooth-enabled tablet computer 110 to retrievecurrent configuration data from a merchant beacon 120. In some suchembodiments, the Bluetooth-enabled tablet computer 110 sends aJavaScript Object Notation (JSON)-formatted request to the merchantbeacon 120 over the Bluetooth communication link 140.

The IoT device 120 receives the request, and responds to the requestingdevice 110 with the requested information in an encrypted formunreadable by the requesting device 110, and including an identifier ortoken of the IoT device 120—Data Flow 220. In the continuing example,the merchant beacon 120 receives the request, and responds to theBluetooth-enabled tablet computer 110 with an encrypted version of thebeacon's 120 current configuration information (including the IoTdevice's identifier), along with an initialization vector (IV), usingthe Bluetooth link 140 between the merchant beacon 120 and the tabletcomputer 110. The tablet computer 110 does not possess a key to decryptthe encrypted configuration information; however, the authorizationdevice 130 does. In some embodiments, the encryption can be based on theAdvanced Encryption Standard (AES); though encryption based on any othershared secret encryption standard can be used. In some embodiments, twosets of public/private key pairs can be used instead of shared secretencryption.

The requesting device 110 forwards a request for processing, theencrypted version of the IoT device 120 information, and the IV to theauthorization device 130 via the first communications network(s)199—Data Flow 230. In the continuing example, the tablet computer 110forwards its request for decryption of the configuration information(including its own identifier), the beacon's 120 encrypted configurationinformation (including the beacon identifier), and the IV to an in-storeserver 130 acting as the authorization device 130 over a TCP/IPcommunications network (such as the store's Wi-Fi network) 199. Anyother server in communication with the Bluetooth-enabled tablet computer110 over the Internet 199 can act as the authorization device 130. Therequest for processing can be in the form of a remote procedure call(RPC) or other suitable format.

The authorization device 130, after receiving the request for processingthe encrypted version of the IoT device 120 information and the IV fromthe requesting device 110, verifies the identity of the requestingdevice 110 and authorization of the user/device to perform the requestedaction, for example, using information contained in the request. In thecontinuing example, the in-store server 130 can use the requestingdevice's identifier in the request sent from the tablet computer 110,and the token from the IoT beacon 120 to determine that one or both ofthe tablet computer 110 and the user thereof is authorized to receivedata from the IoT beacon 120. For example, the in-store server 130 canconfirm that both the tablet computer 110 identifier and the userthereof are listed in an ACL for the identified beacon 120.

The authorization device 130 can then send the IoT device 120information to the requesting device 110 in a form that the requestingdevice can read—Data Flow 240. In the continuing example, the in-storeserver 130 can send the beacon's 120 current configuration informationto the tablet computer 110.

In some embodiments, including an embodiment described below, theresponse form the authorization device 130 to the requesting device 110remains encoded in a way that the requesting device 110 cannot read, butthat the IoT device 120 can read, as an example, using an encryptionscheme shared between the server 130 and the beacon 120 but not sharedwith the requesting device 110.

FIG. 3 is a block flow diagram 300 depicting processes for controllingaccess to IoT devices, in accordance with certain example embodiments.As a further example, consider an IoT device 120 controlling a garagedoor based on messages from a Bluetooth-enabled and 4th generation (4G)Long Term Evolution (LTE)-enabled garage door remote acting as arequesting device 110, and a server, visible to the garage door remoteon the Internet via the 4G LTE link 199, acting as the authorizationdevice 130.

A requesting device 110 first requests from an IoT device 120, andreceives from the IoT device 120, an IoT device identifier of the IoTdevice 120 over a non-TCP/IP communication link 140 between therequesting device 110 and the IoT device 120—Block 310. In the furtherexample, the Bluetooth-enabled and 4G LTE-enabled garage door remote 110requests, and receives, from garage door IoT device 120, the IoT deviceidentifier of the garage door IoT device 120 over a Bluetoothcommunications link 140 between the garage door remote 110 and thegarage door IoT device 120. In some embodiments, the garage door remote110 is a smartphone.

The requesting device 110 second requests, from an authorization device130 over a communication network 199 including at least one TCP/IPcommunication link, authorization to command the identified IoT device130 to perform an action—Block 320. In the further example, the garagedoor remote 110 uses an Internet connection 199 to the server 130 viathe garage door remote's 4G LTE communications channel to transmit anRPC message to the server 130 requesting the server 130 to authorize thegarage door remote 110 to command the garage door IoT device 120 to openthe garage door. The RPC request contains the identifiers for both thegarage door remote 110 and the garage door IoT device 120, along withthe request for the garage door remote 110 to be authorized to performthe command “open” on the garage door through the garage door IoTdevice.

The authorization device 130 receives the second request from therequesting device 110, determines that the requesting device 110 (and,optionally, of a user thereof) is authorized to command the identifiedIoT device 120 to perform the action. For a requesting device 110determined to be authorized to command the identified IoT device 130 toperform the requested action, the authorization device 130 transmits anencrypted authorization for the requesting device 110 to command the IoTdevice 120 to perform the action to the requesting device 110 over thecommunication network 199 including at least one TCP/IP communicationlink—Block 330. Note that in embodiments as described in connection withFIG. 3, the authorization device 130 transmits encrypted informationthat cannot be read by the requesting device 120, but can be read by theIoT device 110. This feature contributes to reducing the risk that anunauthorized third party may intercept an authorization. In someembodiments, to further reduce such risk, the encrypted authorizationcan expire upon a predetermined event, such as closing the garage door,or after a period of time.

In the further example, server 130 receives the RPC requesting theserver 130 to authorize the garage door remote 110 to command the garagedoor IoT device 120 to open the garage door. The server 130 determinesthat the garage door remote 110 is authorized to command the garage doorIoT device 120 to open the garage door by checking one or more ACLsrelated to the garage door remote 110 and the garage door IoT device120. The server 130 then transmits an encrypted authorization (which, inthis example, cannot be read by the garage door remote 110) over theInternet 199 to the remote 110 for commanding the garage door IoT device120 to open the garage door.

The requesting device 110 receives the encrypted authorization via thecommunication network 199 including at least one TCP/IP communicationlink, and relays the encrypted authorization to the IoT device 120 viathe non-TCP/IP communication link 140 between the requesting device 110and the IoT device 120—Block 340. In the continuing example, the garagedoor remote 110 receives the encrypted authorization over the Internet199 for commanding the garage door IoT device 120 to open the garagedoor. The garage door remote 110 relays the encrypted authorization tothe garage door IoT device 120 via the Bluetooth communications link 140between the garage door remote 110 and the garage door IoT device 120.

The IoT device 120 receives the encrypted authorization from therequesting device 110 via the non-TCP/IP communication link 140 betweenthe requesting device 110 and the IoT device 120, decrypts the receivedauthorization, and performs the action specified in theauthorization—Block 350. In the continuing example, the garage door IoTdevice 120 receives the encrypted command to open from the garage doorremote 110 via the Bluetooth link 140, decrypts the command, and opensthe garage door.

Other Example Embodiments

FIG. 4 depicts a computing machine 2000 and a module 2050 in accordancewith certain example embodiments. The computing machine 2000 maycorrespond to any of the various computers, servers, mobile devices,embedded systems, or computing systems presented herein. The module 2050may comprise one or more hardware or software elements configured tofacilitate the computing machine 2000 in performing the various methodsand processing functions presented herein. The computing machine 2000may include various internal or attached components such as a processor2010, system bus 2020, system memory 2030, storage media 2040,input/output interface 2060, and a network interface 2070 forcommunicating with a network 2080.

The computing machine 2000 may be implemented as a conventional computersystem, an embedded controller, a laptop, a server, a mobile device, asmartphone, a set-top box, a kiosk, a router or other network node, avehicular information system, one more processors associated with atelevision, a customized machine, any other hardware platform, or anycombination or multiplicity thereof. The computing machine 2000 may be adistributed system configured to function using multiple computingmachines interconnected via a data network or bus system.

The processor 2010 may be configured to execute code or instructions toperform the operations and functionality described herein, managerequest flow and address mappings, and to perform calculations andgenerate commands. The processor 2010 may be configured to monitor andcontrol the operation of the components in the computing machine 2000.The processor 2010 may be a general purpose processor, a processor core,a multiprocessor, a reconfigurable processor, a microcontroller, adigital signal processor (“DSP”), an application specific integratedcircuit (“ASIC”), a graphics processing unit (“GPU”), a fieldprogrammable gate array (“FPGA”), a programmable logic device (“PLD”), acontroller, a state machine, gated logic, discrete hardware components,any other processing unit, or any combination or multiplicity thereof.The processor 2010 may be a single processing unit, multiple processingunits, a single processing core, multiple processing cores, specialpurpose processing cores, co-processors, or any combination thereof.According to certain embodiments, the processor 2010 along with othercomponents of the computing machine 2000 may be a virtualized computingmachine executing within one or more other computing machines.

The system memory 2030 may include non-volatile memories such asread-only memory (“ROM”), programmable read-only memory (“PROM”),erasable programmable read-only memory (“EPROM”), flash memory, or anyother device capable of storing program instructions or data with orwithout applied power. The system memory 2030 may also include volatilememories such as random access memory (“RAM”), static random accessmemory (“SRAM”), dynamic random access memory (“DRAM”), and synchronousdynamic random access memory (“SDRAM”). Other types of RAM also may beused to implement the system memory 2030. The system memory 2030 may beimplemented using a single memory module or multiple memory modules.While the system memory 2030 is depicted as being part of the computingmachine 2000, one skilled in the art will recognize that the systemmemory 2030 may be separate from the computing machine 2000 withoutdeparting from the scope of the subject technology. It should also beappreciated that the system memory 2030 may include, or operate inconjunction with, a non-volatile storage device such as the storagemedia 2040.

The storage media 2040 may include a hard disk, a floppy disk, a compactdisc read only memory (“CD-ROM”), a digital versatile disc (“DVD”), aBlu-ray disc, a magnetic tape, a flash memory, other non-volatile memorydevice, a solid state drive (“SSD”), any magnetic storage device, anyoptical storage device, any electrical storage device, any semiconductorstorage device, any physical-based storage device, any other datastorage device, or any combination or multiplicity thereof. The storagemedia 2040 may store one or more operating systems, application programsand program modules such as module 2050, data, or any other information.The storage media 2040 may be part of, or connected to, the computingmachine 2000. The storage media 2040 may also be part of one or moreother computing machines that are in communication with the computingmachine 2000 such as servers, database servers, cloud storage, networkattached storage, and so forth.

The module 2050 may comprise one or more hardware or software elementsconfigured to facilitate the computing machine 2000 with performing thevarious methods and processing functions presented herein. The module2050 may include one or more sequences of instructions stored assoftware or firmware in association with the system memory 2030, thestorage media 2040, or both. The storage media 2040 may thereforerepresent examples of machine or computer readable media on whichinstructions or code may be stored for execution by the processor 2010.Machine or computer readable media may generally refer to any medium ormedia used to provide instructions to the processor 2010. Such machineor computer readable media associated with the module 2050 may comprisea computer software product. It should be appreciated that a computersoftware product comprising the module 2050 may also be associated withone or more processes or methods for delivering the module 2050 to thecomputing machine 2000 via the network 2080, any signal-bearing medium,or any other communication or delivery technology. The module 2050 mayalso comprise hardware circuits or information for configuring hardwarecircuits such as microcode or configuration information for an FPGA orother PLD.

The input/output (“I/O”) interface 2060 may be configured to couple toone or more external devices, to receive data from the one or moreexternal devices, and to send data to the one or more external devices.Such external devices along with the various internal devices may alsobe known as peripheral devices. The I/O interface 2060 may include bothelectrical and physical connections for operably coupling the variousperipheral devices to the computing machine 2000 or the processor 2010.The I/O interface 2060 may be configured to communicate data, addresses,and control signals between the peripheral devices, the computingmachine 2000, or the processor 2010. The I/O interface 2060 may beconfigured to implement any standard interface, such as small computersystem interface (“SCSI”), serial-attached SCSI (“SAS”), fiber channel,peripheral component interconnect (“PCP”), PCI express (PCIe), serialbus, parallel bus, advanced technology attached (“ATA”), serial ATA(“SATA”), universal serial bus (“USB”), Thunderbolt, FireWire, variousvideo buses, and the like. The I/O interface 2060 may be configured toimplement only one interface or bus technology. Alternatively, the I/Ointerface 2060 may be configured to implement multiple interfaces or bustechnologies. The I/O interface 2060 may be configured as part of, allof, or to operate in conjunction with, the system bus 2020. The I/Ointerface 2060 may include one or more buffers for bufferingtransmissions between one or more external devices, internal devices,the computing machine 2000, or the processor 2010.

The I/O interface 2060 may couple the computing machine 2000 to variousinput devices including mice, touch-screens, scanners, electronicdigitizers, sensors, receivers, touchpads, trackballs, cameras,microphones, keyboards, any other pointing devices, or any combinationsthereof. The I/O interface 2060 may couple the computing machine 2000 tovarious output devices including video displays, speakers, printers,projectors, tactile feedback devices, automation control, roboticcomponents, actuators, motors, fans, solenoids, valves, pumps,transmitters, signal emitters, lights, and so forth.

The computing machine 2000 may operate in a networked environment usinglogical connections through the network interface 2070 to one or moreother systems or computing machines across the network 2080. The network2080 may include wide area networks (WAN), local area networks (LAN),intranets, the Internet, wireless access networks, wired networks,mobile networks, telephone networks, optical networks, or combinationsthereof. The network 2080 may be packet switched, circuit switched, ofany topology, and may use any communication protocol. Communicationlinks within the network 2080 may involve various digital or an analogcommunication media such as fiber optic cables, free-space optics,waveguides, electrical conductors, wireless links, antennas,radio-frequency communications, and so forth.

The processor 2010 may be connected to the other elements of thecomputing machine 2000 or the various peripherals discussed hereinthrough the system bus 2020. It should be appreciated that the systembus 2020 may be within the processor 2010, outside the processor 2010,or both. According to certain example embodiments, any of the processor2010, the other elements of the computing machine 2000, or the variousperipherals discussed herein may be integrated into a single device suchas a system on chip (“SOC”), system on package (“SOP”), or ASIC device.

In situations in which the systems discussed here collect personalinformation about users, or may make use of personal information, theusers may be provided with an opportunity or option to control whetherprograms or features collect user information (e.g., information about auser's social network, social actions or activities, profession, auser's preferences, or a user's current location), or to control whetherand/or how to receive content from the content server that may be morerelevant to the user. In addition, certain data may be treated in one ormore ways before it is stored or used, so that personally identifiableinformation is removed. For example, a user's identity may be treated sothat no personally identifiable information can be determined for theuser, or a user's geographic location may be generalized where locationinformation is obtained (such as to a city, ZIP code, or state level),so that a particular location of a user cannot be determined. Thus, theuser may have control over how information is collected about the userand used by a content server.

Embodiments may comprise a computer program that embodies the functionsdescribed and illustrated herein, wherein the computer program isimplemented in a computer system that comprises instructions stored in amachine-readable medium and a processor that executes the instructions.However, it should be apparent that there could be many different waysof implementing embodiments in computer programming, and the embodimentsshould not be construed as limited to any one set of computer programinstructions. Further, a skilled programmer would be able to write sucha computer program to implement an embodiment of the disclosedembodiments based on the appended flow charts and associated descriptionin the application text. Therefore, disclosure of a particular set ofprogram code instructions is not considered necessary for an adequateunderstanding of how to make and use embodiments. Further, those skilledin the art will appreciate that one or more aspects of embodimentsdescribed herein may be performed by hardware, software, or acombination thereof, as may be embodied in one or more computingsystems. Moreover, any reference to an act being performed by a computershould not be construed as being performed by a single computer as morethan one computer may perform the act.

The example embodiments described herein can be used with computerhardware and software that perform the methods and processing functionsdescribed herein. The systems, methods, and procedures described hereincan be embodied in a programmable computer, computer-executablesoftware, or digital circuitry. The software can be stored oncomputer-readable media. For example, computer-readable media caninclude a floppy disk, RAM, ROM, hard disk, removable media, flashmemory, memory stick, optical media, magneto-optical media, CD-ROM, etc.Digital circuitry can include integrated circuits, gate arrays, buildingblock logic, field programmable gate arrays (FPGA), etc.

The example systems, methods, and acts described in the embodimentspresented previously are illustrative, and, in alternative embodiments,certain acts can be performed in a different order, in parallel with oneanother, omitted entirely, and/or combined between different exampleembodiments, and/or certain additional acts can be performed, withoutdeparting from the scope and spirit of various embodiments. Accordingly,such alternative embodiments are included in the scope of the followingclaims, which are to be accorded the broadest interpretation toencompass such alternate embodiments.

Although specific embodiments have been described above in detail, thedescription is merely for purposes of illustration. It should beappreciated, therefore, that many aspects described above are notintended as required or essential elements unless explicitly statedotherwise. Modifications of, and equivalent components or actscorresponding to, the disclosed aspects of the example embodiments, inaddition to those described above, can be made by a person of ordinaryskill in the art, having the benefit of the present disclosure, withoutdeparting from the spirit and scope of embodiments defined in thefollowing claims, the scope of which is to be accorded the broadestinterpretation so as to encompass such modifications and equivalentstructures. For example, while some embodiments disclosed herein arebased on an architecture comprising a Bluetooth personal area network(PAN) between the IoT device and the requesting device, and a TCP/IPlocal area network (LAN)/wide area network (WAN) between the requestingdevice and the authorization device, the principles of the technologyapply as well to architectures that include any PAN between an IoTdevice (a device without a direct or reliable LAN/WAN connection to theauthorization device) using the PAN to the requesting device to exchangeinformation with the authorization device over a requesting device'sLAN/WAN connection. In some embodiments, the link between the IoT deviceand the requesting device can be TCP/IP. For example, the IoT devicemight not have a reliable connection to the Internet, but it couldestablish a Wi-Fi Direct connection directly with the requesting device.

1-20. (canceled)
 21. A computer-implemented method to controlcommunication between devices, comprising: requesting, by a firstdevice, from an authorization device and via a first communicationnetwork, an action to be performed by a second device; determining, bythe authorization device in response to receiving the request, anauthorization of the first device to request that the second deviceperform the action; for the first device determined by the authorizationdevice to be authorized to request that the second device perform theaction, communicating, by the authorization device with the first deviceover the first communication network, an authorization authorizing thefirst device to perform the action, the authorization encrypted andsecured from decryption by the first device; relaying, by the firstdevice to the second device via a communication link other than thefirst communication network, the received transmitted encryptedauthorization; decrypting, by the second device, the relayedauthorization; determining, by the second device, that the decryptedauthorization is valid; and performing, by the second device theauthorized action in response to a valid decrypted authorization. 22.The method of claim 21, wherein the second device and the authorizationdevice are not in communication over the first communication network.23. The method of claim 21: wherein the second device comprises abeacon; prior to the requesting, the first device receives a beaconbroadcast of the second device comprising a second device identifier;and the request comprises the second device identifier.
 24. The methodof claim 23, wherein the beacon is a Bluetooth personal area network(PAN) beacon.
 25. The method of claim 20, wherein the broadcast is aJavaScript Object Notation (JSON)-formatted request over the BluetoothPAN.
 26. The method of claim 21, wherein the requesting is a RemoteProcedure Call (RPC) over the communication network including at leastone TCP/IP communication link.
 27. The method of claim 21, wherein theauthorization expires upon one of a pre-determined condition and apredetermined period of time.
 28. A computer program product,comprising: a non-transitory computer-readable storage device havingcomputer-executable program instructions embodied thereon that whenexecuted by a computer cause the computer to: request, by a firstdevice, from an authorization device and via a first communicationnetwork, an action to be performed by a second device; determine, by theauthorization device in response to receiving the request, anauthorization of the first device to request that the second deviceperform the action; for the first device determined by the authorizationdevice to be authorized to request that the second device perform theaction, communicate, by the authorization device with the first deviceover the first communication network, an authorization authorizing thefirst device to perform the action, the authorization encrypted andsecured from decryption by the first device; relay, by the first deviceto the second device via a communication link other than the firstcommunication network, the received transmitted encrypted authorization;decrypt, by the second device, the relayed authorization; determine, bythe second device, that the decrypted authorization is valid; andperform, by the second device the authorized action in response to avalid decrypted authorization.
 29. The computer program product of claim28, wherein the second device and the authorization device are not incommunication over the first communication network.
 30. The computerprogram product of claim 28: wherein the second device comprises abeacon; prior to the requesting, the first device receives a beaconbroadcast of the second device comprising a second device identifier;and the request comprises the second device identifier.
 31. The computerprogram product of claim 30, wherein the beacon is a Bluetooth personalarea network (PAN) beacon.
 32. The computer program product of claim 31,wherein the broadcast is a JavaScript Object Notation (JSON)-formattedrequest over the Bluetooth PAN.
 33. The computer program product ofclaim 28, wherein the requesting is a Remote Procedure Call (RPC) overthe communication network including at least one TCP/IP communicationlink.
 34. The computer program product of claim 28, wherein theauthorization expires upon one of a pre-determined condition and apredetermined period of time.
 35. A system to control communicationbetween devices, the system comprising: at least one storage device; andat least one processor communicatively coupled to the ay least onestorage device, wherein the processor executes application codeinstructions that are stored in the storage device to cause the systemto: request, by a first device, from an authorization device and via afirst communication network, an action to be performed by a seconddevice; determine, by the authorization device in response to receivingthe request, an authorization of the first device to request that thesecond device perform the action; for the first device determined by theauthorization device to be authorized to request that the second deviceperform the action, communicate, by the authorization device with thefirst device over the first communication network, an authorizationauthorizing the first device to perform the action, the authorizationencrypted and secured from decryption by the first device; relay, by thefirst device to the second device via a communication link other thanthe first communication network, the received transmitted encryptedauthorization; decrypt, by the second device, the relayed authorization;determine, by the second device, that the decrypted authorization isvalid; and perform, by the second device the authorized action inresponse to a valid decrypted authorization.
 36. The system of claim 35,wherein the second device and the authorization device are not incommunication over the first communication network.
 37. The system ofclaim 35: wherein the second device comprises a beacon; prior to therequesting, the first device receives a beacon broadcast of the seconddevice comprising a second device identifier; and the request comprisesthe second device identifier.
 38. The system of claim 37, wherein thebeacon is a Bluetooth personal area network (PAN) beacon.
 39. The systemof claim 38, wherein the broadcast is a JavaScript Object Notation(JSON)-formatted request over the Bluetooth PAN.
 40. The system of claim35, wherein the requesting is a Remote Procedure Call (RPC) over thecommunication network including at least one TCP/IP communication link.